Mobile computing devices, such as mobile or wireless stations, cell phones, radios, laptops, wireless communication devices and the like, operate with a power storage device with a limited energy supply, such as a battery, fuel cell or the like. A mobile computing device needs a power source and, in many cases, this power source is a battery. For instance, cellular phones use various types of batteries to operate. The amount of time a mobile station can typically operate before the energy of the battery is consumed (which is often referred to as “battery life”), is often an important criteria that consumers use in choosing one brand or type of mobile computing device over another brand. The terms battery, energy storage device and power storage device are used interchangeably herein.
While the power storage device is generally rechargeable, it may not be convenient or even possible for a user to recharge. Accordingly, there is a need to maximize the useful operational time of a wireless computing device.
Additionally, different operating environments can cause the user to be surprised and/or frustrated when the battery runs out much more quickly than would typically be expected by the user. Thus, a variation or unexpected short battery life is very undesirable from a user perspective.
This is a particularly relevant problem for mobile computing devices running applications supported by an applications server because of the power drain due to the wireless data exchange between the mobile device and the server, since each upload or download causes the consumption of energy in the mobile device and server. The problem is especially acute in the mobile device, which is typically battery powered and has finite energy available.
Accordingly, it is desirable to improve battery life of mobile devices operating on any network. For example, in connection with the operation of a 3G network, a mobile device is typically in a persistent internet communication with an application server. It is desirable to reduce the inefficiencies of sending and receiving very short messages on the 3G network.
As background, persistent internet connection methods were adopted for general use with hypertext transfer protocol (HTTP) version 1.1 some time ago. Prior to persistent connections, a separate TCP connection was established to fetch each URL, increasing the load on HTTP servers and causing congestion on the Internet. With persistent TCP/IP communications a TCP/IP connection remains open unless the server or client signals the connection to close. In practice, servers and network gateways maintain a time-out period after which they will no longer maintain an inactive connection. It is common practice for mobile devices in persistent communication with an application server to employ a periodic keep-alive message, also called heartbeat, to maintain the persistent connection beyond the timeout period.
In order to reduce energy consumption in the mobile device due to reception of unwanted TCP/IP messages, mobile devices generally employ firewall techniques whereby TCP/IP sessions cannot be initiated except by the mobile device itself. The application server is typically only able to send application related data to the mobile client if a TCP/IP connection is persistent and maintained active. Typically the mobile client will open a TCP/IP session at the time the application is started or the device powers up, and periodically sends keep alive messages to prevent the server or network gateway from closing the session. The server will send, or “push’, over the TCP/IP connection frequent notification messages which indicate a change in the application state or the availability of new data. In response the mobile device may request, or “pull”, related application data from the server.
The keep-alive and notification messages typically contain on the order of 100 bytes of data. Sending and receiving such small messages on a normal 3G data channel has an inefficient and undesirable impact on power dissipation in a mobile device. This is because the radio resource controller (RRC) on the 3G networks requires the device to transition from the idle state, to a fast associated control channel (FACH) state having high current drain, and then to a dedicated channel (DCH) state also having high current drain, before sending the 100 bytes of data. The RRC then keeps the mobile in the DCH state and FACH states for typically 6 to 16 seconds. For example, on a typical 3G handset the idle state current drain is about 2 mA, the DCH/FACH state current drain is about 200 mA. On a T-Mobile network, a device and network remains in the DCH/FACH state for approximately 6 seconds. On an AT&T network, the device remains in the DCH/FACH state for approximately 16 seconds. The amount of battery capacity consumed by a handset, due to the 100 byte message is 0.33 mAh on T-Mobile and 0.89 mAh on AT&T. For a light data user, keep-alive and notifications messages are typically exchanged on the order of 12 times per hour (for a light user), thus causing additional current drain of about 3.9 mA on T-Mobile and 10.7 mA on AT&T. As can be seen, the effect on battery life can be significant.
Maintaining an active TCP/IP session for receiving “push” notifications has another side-effect, in it makes the mobile vulnerable to unwanted traffic, such as spurious IP messages from unknown sources, or malicious attacks.
It would be considered an improvement in the art, if the energy drain due to keep-alive and notification messages from application servers, as well as spurious or malicious messages from unknown sources, could be reduced or eliminated. It would also be considered an improvement in the art, if current drain could be minimized in the above examples, thereby extending battery life in a mobile device.
Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions and/or relative positioning of some of the elements in the figures may be exaggerated relative to other elements to help to improve the understanding of various embodiments of the present invention. Also, common but well-understood elements that are useful or necessary in a commercially feasible embodiment are often not depicted in order to facilitate a less obstructed view of these various embodiments of the present invention. It will further be appreciated that certain actions and/or steps may be described or depicted in a particular order of occurrence while those skilled in the art will understand that such specificity with respect to sequence is not actually required. It will also be understood that the terms and expressions used herein have the ordinary meaning as is accorded to such terms and expressions with respect to their corresponding respective areas of inquiry and study except where specific meanings have otherwise been set forth herein.